Fixes #5850

If no signing identity is present while an app is built and it is downloaded via a web browser, macOS on ARM shows "app is damaged" errors that are hard to bypass for the average user (see #5850 and some other duplicates). This seems to be because the default signature applied by the linker to the executables isn't valid due to something the build system is doing [1]. It is thus an error to not manually codesign the resulting app, even if no stable signing identity is available (in which case it must be an ad-hoc signature).

The damaged warning is not the same as the unverified warning. Not paying for a developer account does not mean your app must show "this app is damaged" warnings to users, but it will show an unverified warning. The damaged warning cannot be bypassed through the GUI (such as in System Settings) and requires running commands to remove the quarantine attribute (as of the current macOS version). An unverified warning, on the other hand, has supported GUI methods of bypassing the warning and running the app. A proper (free) ad-hoc signature means that the damaged warning will not show up, but the unverified warning will.

Since there are no problems for those with "proper" signing certificates, it follows that the existing signing system does make a valid signature, and if it can be repurposed to accept empty identities (for ad-hoc signatures), this will resolve the issue. This PR does two main things:

• Add an option to use ad-hoc signatures by passing - as the identity. This is the same convention that the codesign command uses.
• Use ad-hoc signatures as a fallback by default when building ARM or universal builds if no valid identity is present. This can be overridden by setting the identity to null.

I tested these changes with FreeTube, which previously showed "'FreeTube' is damaged" warnings.
Before these changes, the warning looks like the below and can't be bypassed in System Settings.

With these changes, the new warning looks like

And System Settings shows an option to bypass the warning like it does on Intel.

[1] For additional details if you're curious, see the macOS 11.0.1 release notes. Specifically (emphasis mine):

To reduce the impact on existing development workflows, starting with Xcode 12 beta 4, the toolchain will now automatically sign your executables whenever you build from Xcode, or use command-line utilities such as clang(1) or ld(1). Since this signing mechanism generates signatures directly at link time, and doesn’t cover any resource other than the executable, it is expected to be faster than a traditional codesign(1) invocation. If you use a custom workflow involving tools that modify a binary after linking (e.g. strip or install_name_tool) you might need to manually call codesign(1) as an additional build phase to properly ad-hoc sign your binary.